Publish-subscribe system

ABSTRACT

A publish-subscribe system publishes events associated with one or more objects represented by files within a file system. The files may be accessed using a file system application programming interface by both publishers and subscribers. Each file may contain an identifier and a plurality of attributes and each attribute may have a name and a value. The files and the associated objects may be persisted to compensate for restarts and failures of a computing platform hosting the system for publish-subscribe.

PRIORITY CLAIM

This application is a continuation of U.S. Ser. No. 12/780,400, entitled“Publish and Subscribe,” filed May 14, 2010, which is incorporated byreference.

BACKGROUND OF THE INVENTION

1. Technical Field

This disclosure relates to a publish-subscribe communication system.

2. Related Art

A publish-subscribe system may allow publishers to publish eventsassociated with objects that may be distributed to many recipients knownas subscribers. Rather than sending publish events to specificreceivers, each publish event is associated with one of one or moreobjects. Subscribers interested in one or more objects may elect toreceive publish events by subscribing to objects of interest, with orwithout knowledge of the publishers.

There is a proliferation of different publish-subscribe systems withlittle uniformity in the interfaces for publishers and subscribers.Software developers may be reluctant to adapt their publisher andsubscriber application implementations to multiple interfaces and as aresult the potential for leveraging these application implementations isreduced.

SUMMARY

A publish-subscribe system publishes events associated with one or moreobjects represented by files within a file system. The publish-subscribefiles may be accessed through file system software implemented byapplications, libraries, and/or an operating system stored on anon-transitory medium. The file system software may comprise a filesystem application programming interface that provides access topublishers and subscribers. The publish-subscribe files may comprise anidentifier and one or more attributes. The attributes may be associatedwith a name and may include one or more values. The publish-subscribefiles and some or all of the associated objects may persist overrestarts and failures of a computing platform hosting thepublish-subscribe system and may be retained in a persistent file systemand/or a non-volatile medium such as a storage device.

In some publish-subscribe systems one or more publishers may be coupledto one or more subscribers through an asynchronous device that publishesevents associated with one or more objects that may not be synchronizedwith other parts of a communication system. A local or remote controlleror device in a distributed architecture may publish events using acommon file system application programming interface. The subscribersmay access the publish events though the same file system applicationprogramming interface used by the publishers. The subscribers mayreceive notifications (e.g., such as the creation, modification anddeletion of publish-subscribe files) and retrieve details of the eventsusing the same file system application programming interface.

Other systems, methods, features and advantages of the invention willbe, or will become, apparent to one with skill in the art uponexamination of the following figures and detailed description. It isintended that all such additional systems, methods, features andadvantages be included within this description, be within the scope ofthe invention, and be protected by the following claims.

BRIEF DESCRIPTION OF THE DRAWINGS

The invention can be better understood with reference to the followingdrawings and description. The components in the figures are notnecessarily to scale, emphasis instead being placed upon illustratingthe principles of the invention. Moreover, in the figures, likereferenced numerals designate corresponding parts throughout thedifferent views.

FIG. 1 is a publish-subscribe system.

FIG. 2 is an alternative publish-subscribe system.

FIG. 3 is an exemplary logical publish-subscribe file.

FIG. 4 is an exemplary system of FIG. 2.

FIG. 5 is a second exemplary system of FIG. 2.

FIG. 6 is an exemplary output of a read operation of a directory openedin a delta mode.

FIG. 7 is an exemplary publish-subscribe process.

DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

A publish-subscribe system allows publishers of messages to sendmessages to subscribers through a publish-subscribe file system that maybe stored on a non-volatile storage medium. By distilling thefunctionality of one or more publish-subscribe architectures into ahierarchical file arrangement, the publish-subscribe system may hide thedetails of one or more static or dynamic publish-subscribe systems. Thesystem allows for greater scalability, device independence, and a moredynamic and flexible communication network.

FIG. 1 is a publish-subscribe system 100. The publishers 110 and thesubscribers 120 may be loosely-coupled as either may be withoutknowledge of the other. In the publish-subscribe system of FIG. 1,middleware such as a broker 130 may provide a store-and-forwardfunctionality to route data-bearing events between the publisher 110 andthe subscriber 120 applications. Publishers 110 may publish events 112to the broker 130 through a publish application programming interface140. Subscribers 120 may transmit subscribe 122 and unsubscribe 126requests through a wireless and/or physical mediums and networks toreceive notifying events 124 though a subscribe application programinterface 150. The notify events 124 may forward the contents of publishevents 112 to distributed devices and subscribers 120. In some systems,published events 112 are not persisted and do not survive a systemrestart or a failure of the publish-subscribe system 100.

FIG. 2 is an alternative publish-subscribe system 200. The system 200may comprise a file system application programming interface 205, a filesystem manager 210, file system content 220, one or more publisherapplications 260, and one or more subscriber applications 240. In somesystems, the file system application programming interface 205 providesfunctionality (e.g., procedure calls) that may include, for example,open( ), write( ), read( ) and close( ) that may be invoked byprocessors and applications (e.g., publisher applications 260 andsubscriber applications 240). The syntax or protocol that is used tomake calls these or other functions may require more or less calldetail, may or may not include the data and/or storage location that maydrive them, may have different semantics, syntax, and/or forms (as manydifferent programming languages and interface specifications may beused). In some systems, the invocation of the function may includearguments such as, for example, a pathname, a file descriptor, inputvariables, and return variables. These and other systems may include afile system application programming interface 205 of a computer systemthat may be compliant with standards established by a standard settingorganization. For example, some publish-subscribe systems 200 arecompliant with a file system application programming interface standardadopted by the Institute of Electrical and Electronics Engineers (IEEE).The IEEE Portable Operating System Interface (POSIX) 1003.1specification is incorporate herein by reference in its entirety. Whilesome or all of systems described may be POSIX compliant and include thefunctionality of POSIX specification, the publish-subscribe systems arenot limited to such standard and may be compliant with multiplestandards or no standards.

In FIG. 2, the file system manager 210 that may be hosted by a server orcontroller. The file system manager 210 may invoke translations from theoriginal or native commands received from the publisher or subscriberinto the corresponding operations supported on the file system content220 that may be distributed or local to the server or controller hostingthe file system manager. Such operation may include, for example,create, modify and delete, mount-points, transactionality (e.g.,snapshots and copy-on-write (COW)) and other similar or differentfunctions.

In FIG. 2, the file system content 220 includes directories and filesthat may be arranged in a hierarchical arrangement as shown or in anon-hierarchical arrangement (not shown). Each file and directory mayhave a corresponding file name or directory name. The file systemcontent may include at least one publish-subscribe mount-point (e.g.,/fs/ps) 223 under which may be contained a plurality ofpublish-subscribe files (e.g., publish-subscribe files 251, 252, 253,254) and directories (e.g., directories 224, 225, 226). Some or eachpublish-subscribe file may represent a published object in thepublish-subscribe system 200. Some or each file and directory may beuniquely identified (e.g., addressed) within a pathname space by itspathname. In some systems, a pathname for a given file or directory maybe comprised of a mount-point name followed by the names of each of anyintervening directories separated by a separator character (e.g., ‘/’),followed by the given file name or directory name. In alternativesystems, pathnames may have different formats.

FIG. 3 is an exemplary logical publish-subscribe file 300. Thepublish-subscribe file 300 may include an object identifier 310 whichmay comprise the name given to the file (e.g., current play) preceded byan identifier prefix such as, for example, the character ‘@’. Thepublish-subscribe file 300 may or may not contain attributes 320. Eachattribute 320 may comprise a tag, an encoding type, and a value (e.g.,author:\t:Beatles). The tag 330 may identify the attribute name (e.g.,author). The encoding type 360 (e.g., \t) may represents a type of dataencoding that is applied to the value 340. The value 340 represents avalue for the attribute (e.g., Beatles). The value 340 may be, forexample, a sequence of characters excluding a linefeed character or anull character. The encoding type may, for example, be based on aprogramming language specific encoding types such as C programminglanguage escape sequences (e.g., \n, \t). The tag 330, the encoding type360 and the value 340 may be separated by a separator character 350 suchas a colon (e.g., author:\t:Beatles). When the encoding type 360 is notprovided (e.g., author::Beatles), a default encoding type may be used(e.g., a sequence of text characters terminated by a linefeedcharacter). Successive attributes 320 may, for example, be separated bylinefeed characters. In an alternative system, each attribute 320 maycomprise a tag 330 and a value 340 separated by a separator character350 without an encoding type. While the contents of thepublish-subscribe file 300 are shown in human readable format;alternatively the contents of the publish-subscribe file 300 may be in anon-human readable format such as machine readable binary format.

Any of the one or more publisher applications 260 may invoke functionsin the file system application programming interface 205 to causecreation of one or more objects, when the objects did not previouslyexist, and to publish events associated with the objects. A publisherapplication 260 may prepare to publish to an object by invoking a fileopen( ) function in the file system application programming interface205 (hereinafter referred to as opening the file) in a write-only mode.Alternatively, the publisher 260 may open the publish-subscribe file 300in a read-write-mode thereby both preparing to publish to and alsosubscribing to the object. The opening of the file may comprise anon-blocking operation. Opening a publish-subscribe file 300 that doesnot already exist may optionally cause the creation of thepublish-subscribe file 300 with no attributes 320. Arguments provided bythe publisher application 260 in the file open( ) function invocationmay include any of: an object name, a pathname, a file name, an accessmode, and/or other access points. The invocation of the file open ( )function may return a file descriptor or a file handle that may be usedin subsequent invocations of other functions in the file systemapplication programming interface to refer to the openedpublish-subscribe file 300.

After a publisher application 260 has prepared to publish an object byopening the associated publish-subscribe file (e.g., any ofpublish-subscribe files 251, 252, 253, 254), the publisher application260 may publish events associated with the object by invoking a filewrite( ) function in the file system application programming interface205. When a new attribute 320 (e.g., one that does not already exist inthe publish-subscribe file) is included, in a data element to the filewrite operation, the attribute 320 may be added to the publish-subscribefile. When an existing attribute 320 is included, in a data element tothe file write operation, the corresponding attribute 320 in theexisting publish-subscribe file 300 may be modified. A write operationcontaining, in a data element to the file write operation, an attributetag preceded by an attribute deletion flag (e.g., ‘-’) may delete theattribute. Opening a publish-subscribe file 300 in truncate mode maydelete all existing attributes 320. The arguments in a file writeoperation may optionally include an object identifier.

Multiple publishers applications 260 may open and publish (e.g., write)to the same object. The different publishers 260 may for example, eachupdate different attributes 320, or alternatively more than onepublisher 260 may update the same attribute 320 in a publish-subscribefile 300. When one or more attributes 320 are included in a file writeoperation by the publisher 260, other existing attributes 320 in thepublish-subscribe file 300 are not affected (e.g., not modified). Whenwriting an object, a publisher 260 may associate a quality parameterwith each attribute 320. In some systems, the attribute 320 in thepublish-subscribe file 300 is only modified when the quality associatedwith the attribute 320 in the write operation is equal to or higher thana quality associated with the attribute 320 already contained in thepublish-subscribe file 300. The quality may, for example, be an integervalue between 0 and 9 with larger integers representing higher qualityvalues. When no quality value is explicitly associated with an attribute320 in a write operation, the quality may default to the lowest qualityvalue (e.g., 0).

Any of the one or more subscriber applications 240 (through processors,controllers, etc.) may invoke functions in the file system applicationprogramming interface 205 to subscribe to one or more objects and toreceive publish events associated with the objects. A subscriberapplication 240 (through processors, controllers, etc.) may subscribe toan object by opening the corresponding publish-subscribe file (e.g., anyof publish-subscribe files 251, 252, 253, 254) in a read mode (e.g.,read-only). The subscriber application 240 may receive publish eventsassociated with the subscribed object by receiving a notification andresponsive to the notification invoking a read ( ) function in the filesystem application programming interface 205 (hereinafter referred to asreading the file). Alternatively, the subscriber application 240 mayreceive publish events associated with the subscribed object by readingthe file without receiving a notification.

The subscriber application 240 may open a publish-subscribe file 300 ineither full or delta mode. When the publish-subscribe file 300 is openedin a full mode the subscriber may receive a single consistent version ofthe contents (e.g., identifier 310 and attributes 320) of the objectwhenever the publish-subscribe file 300 is read. When a publisher 260publishes events associated with an object several times before asubscriber 240 reads the publish-subscribe file 300, the subscriber 240may receive the current state of the publish-subscribe file 300 contentat the time of the file read. In those circumstances where thesubscriber 240 has also requested publication event notification for theobject, the subscribe 240 may receive notifications for each subsequentpublish event for the object.

The publish-subscribe system 200 may interface or couple many systemsincluding one or more media players (not illustrated). Apublish-subscribe file 300 may represent an object called current playthat models a currently playing media content item. A media player userinterface may be a publisher application 260 that creates the currentplay publish-subscribe file 300 and initially publishes the contents ofauthor, album, title, duration and time attributes. A media playbackmanager may also be a publisher application 260 that repeatedlypublishes updates to the time attribute as the play time of the mediacontent item changes. The media player user interface may also be asubscriber application 240 that subscribes to the current playpublish-subscribe file 300, receives the events (e.g., updates)published by the media playback manager and refreshes a display of themedia play time on the user interface.

When the publish-subscribe file 300 is opened in a delta mode, forexample, the first time a subscriber 240 reads the publish-subscribefile 300, the entire contents (e.g., identifier 310 and attributes 320)of the publish-subscribe file 300 may be returned. After a successfulfile read operation, a change status for the object may be cleared(e.g., is set to unchanged). Subsequent readings of thepublish-subscribe file 300, opened in delta mode, by the subscriber 240may return the identifier 310 and only attributes 320 that have changedsince a preceding successful read of the publish-subscribe file 300.

A non-blocking flag may be associated with the open publish-subscribefile 300 to allow the subscriber 240 to control (e.g., adapt) thebehavior of the file read operation. When the contents of thepublish-subscribe file 300 have not changed since a previous file read(e.g., the change status is unchanged), a file read with thenon-blocking flag set may return immediately with no data, while a fileread with the non-blocking flag clear (e.g., blocking) may wait untilthe object is changed and then returns the contents (e.g., attributes320) that have changed. When not specified by the subscriber 240 in afile open( ) invocation, the non-blocking flag may be set (e.g.,behavior is non-blocking) by default. The default behavior may ensurethat standard file utilities do not block when reading apublish-subscribe file 300 that does not change. The subscriberapplication 240 may unsubscribe from the object by invoking a fileclose( ) function.

Multiple subscribers 240 may subscribe to (e.g., open) the samepublish-subscribe file 300 in a delta mode. A separate change status ismaintained for each subscriber 240 so that each subscriber 240 may seeall of the changes made to the object. A successful file read( ) of thepublish-subscribe file 300 by one subscriber 240 may not clear thechange status for other subscribers 240 of the same publish-subscribefile 300.

The publish-subscribe system 200 may provide a notification mechanism. Asubscriber 240 may request to receive a notification when a publishevent occurs for a specified publish-subscribe file 300 (e.g., object).The notification request may, for example, be in the form of anionotify( ) function call in accordance with a LINUX applicationprogramming interface or QNX Neutrino RTOS application programminginterface. The notification may take the form of a PULSE, a SIGNAL, or aSEMAPHORE as described in any of POSIX, LINUX and QNX Neutrino RTOS,operating system specifications. In other systems, other similarnotification mechanisms may be used. After receiving the notification,the subscriber 240 may invoke a read( ) function on thepublish-subscribe file 300 to obtain the details of the publish event.

A subscriber 240 may subscribe to multiple objects by opening each ofthe associated publish-subscribe files (e.g., any of publish-subscribefiles 251, 252, 253, 254). Alternatively, the subscriber 240 maysubscribe to all objects that are contained in one directory by openingthe directory (e.g., 226). Optionally, the publish-subscribe system 200may provide a proxy file 255 having a predetermined name (e.g., ‘.all’)in each directory and the subscriber 240 may open the proxy file 255 tosubscribe to all objects that are contained in the correspondingdirectory. A read operation, of the directory 226, or of the proxy file255, in full mode may return the contents of one of thepublish-subscribe files (e.g., 252, 253 or 254) representing an object.Each subsequent read operation may return the contents of anotherpublish-subscribe files representing the objects. A read operation indelta mode may return a queue of every attribute change in any of thepublish-subscribe files. The results of the read operation in delta modemay span multiple publish-subscribe files.

FIG. 6 is an exemplary output of a read operation of a directory openedin a delta mode. In this figure the results include attributes from twopublish-subscribe files—Time and PlayCurrent—contained in the openeddirectory. The results include two publication events for the ‘position’attribute in the Time publish-subscribe file and one event for theattributes ‘artist’ and ‘genre’ in the publish-subscribe filePlayCurrent. When a new object (e.g., publish-subscribe file 300) iscreated in the opened directory, the subscriber 240 may receive anotification containing an object creation flag (e.g., ‘+’) followed bythe object identifier (e.g., +@objectname). When an existing object(e.g., publish-subscribe file 300) is deleted in the opened directory,the subscriber 240 receives a notification containing an object deletionflag (e.g., ‘−’) followed by the object identifier (e.g., −@objectname).

Data elements provided to or returned by read( ) and write( ) functioninvocations may contain options for each line containing an object name310 or an attribute 320. The options may be in the form of an opensquare bracket (‘[’) followed by one or more single letter options andfollowed (terminated) by a close square bracket (‘]’). When a letteroption is preceded by a minus sign (‘−’) the option maybe cleared,otherwise the option is set. If the letter option is not specified, theoption is not changed. An ‘n’ option may be used for non-persistence.When the non-persistence option is set for an attribute 320 theattribute will not be persisted when the object containing the attribute320 is persisted. By default the non-persistence options may be cleared(e.g., persistent) for each attribute 320. The non-persistence optionmay be set on an objectname in which case the entire object will be notbe persisted thereby overriding the non-persistence option on individualattributes 320 in the object. Some example attributes with options andthere effects, may include:

[n]url::www.qnx.com Set no-persist option on this attribute[-n]url::www.qnx.com Clear no-persist option on this attributeurl::www.qnx.com No change to the current no-persist option on thisattribute [4]author::Beatles Change author if current quality is lessthen or equal to 4

A quality option may have values of 0 to 9. This option may set aquality associated with an attribute 320. When the option is notspecified, the default quality may be set to ‘0’ (e.g., the lowestpossible value). In some systems, an attribute 320 is only modified whenthe quality associated with a new attribute value, in a write operation,is equal or greater than the quality associated with the currentattribute value in the object. Use of this option may ensure that thequality of an attribute value will only increase when one or morepublishers 260 provide asynchronous publication events containing thesame attribute 320.

When an attribute name 330 is preceded by an attribute deletion flag(e.g., ‘−’) in a write( ) function invocation, a corresponding attribute320 maybe deleted from the object. When a publish-subscribe file 300 isopened in delta mode, receiving an attribute name 330 preceded by theattribute deletion flag (e.g., ‘−’) from a file read operation maysignify that the corresponding attribute 320 has been deleted from theobject.

When a publish-subscribe file 300 is created or deleted, thepublish-subscribe system 200 may queue a notification for eachapplication (e.g., publishers 260 and subscribers 240) that has eitherthe parent directory, of the created or deleted publish-subscribe file300, or the corresponding proxy file opened in either full or deltamode. The notification may include a string such as, for example,‘+@objectname’ or ‘−@objectname’ when the object is created or deletedrespectively.

When an application (e.g., publishers 260 and subscribers 240) has apublish-subscribe file 300 open and the corresponding object is deleted,a read( ) function invocation may return a string such as, for example,‘−@objectname’. The publish-subscribe file 300 maybe closed when thecorresponding object is deleted and only those applications 260, 240that have a file descriptor from a previous open( ) are able to continueto access the publish-subscribe file 300.

File system utilities or commend-line utilities may be used to debugfile system nodes (e.g., publish-subscribe files and directories) usedin the publish-subscribe system 200. For example, a command to displayall objects in the publish-subscribe system 200 may look like:

-   -   ls-IR/fs/ps/

A command to display the current state of two objects may look like:

cat /fs/ps/media/PlayCurrent cat /fs/ps/flash/apps/youtube

A command to change the attributes of an object may look like:

-   -   echo “attr::value”>>/fs/ps/objectfilename

FIG. 7 is an exemplary publish-subscribe process. At 702 a firstinvocation of the file open( ) function for a publish-subscribe file 300is received from a publisher application 260. The first invocation ofthe open( ) function may include a name of the publish-subscribe file300. The publish-subscribe file 300 may represent a publish-subscribeobject. At 704 a second invocation of the file open( ) function for thepublish-subscribe file 300 is received from a subscriber application240. The second invocation of the open( ) function may include the nameof the publish-subscribe file 300. The subscriber application 240 maysubscribe to the publish-subscribe object represented by thepublish-subscribe file 300. At 706 one or more invocations of the filewrite( ) are received from the publisher application 260. The write( )function invocations correspond to publication events for the objectgenerated by the publisher application 260. At 708 an optionalnotification is sent to the subscriber application 240 responsive toreceiving each write( ) invocation at 706. At 710 one or moreinvocations of the file read( ) function are received from thesubscriber application 240. The invocation of the read( ) function maybe responsive to the notification sent at 708. The subscriberapplication 240 receives notification of the publish events for theobject via the notification of step 708 and the read( ) functioninvocations of step 710. Steps 706, 708 and 710 may be repeated forsubsequent invocations of the file write( ) function by the publisherapplication 260, sending of the notifications, and invocations of thefile read( ) function by the subscriber application 240. The file open(), write( ) and read( ) functions may be provided by a file systemapplication programming interface 205. The file system applicationprogramming interface 205 may be compliant with many standards such as aPOSIX compliant application programming interface.

FIG. 4 is an exemplary publish-subscribe system 200. The computingplatform 400 comprises a processor 410, volatile memory 420,non-volatile memory 430, an input/output (I/O) interface 440, a networkinterface 450, an optional human-machine interface (HMI) 460, and asystem bus 470. The volatile memory 420 may, for example, include randomaccess memory (RAM). The non-volatile memory 430 may include, forexample, a hard disk drive (HDD) or a Flash memory device. The systembus 470 provides for communications and interoperation between the othercomponents 410, 420, 430, 440, 450, 460 of the computing platform 400.

FIG. 5 is a second exemplary publish-subscribe system 200 that may beintegrated within or separate from the system of FIG. 4. The exemplaryfunctional components 500 comprise an operating system kernel 510, asoftware bus 520, a process manager 530, a file system 540, aninput/output (I/O) system 550, a user interface 560, a network stack570, and one or more applications 590. The software bus 520 provides forinteroperation between the other components 510, 530, 540, 550, 560,570, 580, and 590 of the arrangement 500 via inter-processcommunications (e.g., messaging, remote procedure calls (RPC)). Thefunctional components 510, 520, 530, 540, 550, 560, 570, 580, 590 may beimplemented using processor 410 executable instructions stored inprocessor accessible memory including volatile memory 420 andnon-volatile memory 430. When a host computing platform is running, thepublish-subscribe nodes (e.g., directories and publish-subscribe files)may be maintained in volatile memory. The publish-subscribe system 200may save objects to a persistent (e.g., non-volatile) store on demand(e.g., on a file close or flush) while running or at shutdown.

The minimum unit of persistence may be a publish-subscribe directory orsub-directory (e.g., 224, 225 or 226). All or some of the objects in thepublish-subscribe directory may be written to persistent store in asingle atomic operation as a single file. Saving the contents (e.g.,objects) of the publish-subscribe directory as a single entity (e.g.,file) may ensure that objects in the publish-subscribe directory thatcontain related or linked data are self-consistent. Only the currentstate (e.g., contents) of each object (e.g., publish-subscribe file) maybe saved to persistent memory in some systems. For publish-subscribefiles 300 that are open in delta mode when they are saved to persistentmemory, the queue of changes (e.g., deltas) may be lost and only thecurrent state of the contents of the object may be saved. When thepublish-subscribe is restored from the saved file (e.g., at start-up),each of the objects contained in the publish-subscribe directory may berecreated in a volatile (or non-volatile) store of a storage media.Alternatively, the minimum unit of persistence may be all of thedirectories, sub-directories and objects under the publish-subscribemount-point 223. In a further alternative, the minimum unit ofpersistence may be individual publish-subscribe files (e.g., objects)that may each be written to persistent store in a separate operation. Onstart-up the file system may restore all publish-subscribe nodes fromthe persistent store to volatile memory immediately or alternativelyeach object may be restored when it is first accessed (a.k.a. deferredloading).

Other alternate systems and methods may include combinations of some orall of the structure and functions described or shown in one or more oreach of the figures. These systems or methods are formed from anycombination of structure and function described or illustrated withinthe figures. Some alternative systems or devices are compliant with oneor more transceiver protocols. Wireless connectivity betweenpublish-subscribe systems, and one or more wireless networks providehigh speed connections that allow users to initiate or complete acommunication at any time while stationary or on the move. The wirelessconnections may provide access to, or transmit, static or dynamiccontent (live audio or video streams, for example). The content mayberelated to entertainment, transactions, or any area or interests.

Each of the systems and methods may be encoded in a signal bearingmedium, a computer readable medium such as a memory, programmed within adevice such as one or more integrated circuits, or processed by acontroller or a computer. If the methods are encoded in software, thesoftware may reside in a memory resident to or interfaced to any othertype of non-volatile or volatile memory interfaced, or resident to acommunication device. The memory may include an ordered listing ofexecutable instructions for implementing logical functions. A logicalfunction may be implemented through digital circuitry, through sourcecode, through analog circuitry, or through an analog source such throughan analog electrical, or optical signal. The software may be embodied inany computer-readable or signal-bearing medium, for use by, or inconnection with an instruction executable system, apparatus, or device.Such a system may include a computer-based system, aprocessor-containing system, or another system that may selectivelyfetch instructions from an instruction executable system, anon-transitory apparatus, or device that may also execute instructions.

A “computer-readable medium,” “machine-readable medium,” and/or“signal-bearing medium” may comprise any apparatus that contains,stores, communicates, or transports data and/or software for use by orin connection with an instruction executable system, apparatus, ordevice. The machine-readable medium may selectively be, but not limitedto, an electronic, magnetic, optical, electromagnetic, infrared, orsemiconductor system, apparatus, devices. A non-exhaustive list ofexamples of a machine-readable medium would include: an electricalconnection “electronic” having one or more tangible connections, aportable magnetic or optical disk, a volatile memory such as a RandomAccess Memory “RAM” (electronic), a Read-Only Memory “ROM” (electronic),an Erasable Programmable Read-Only Memory (EPROM or Flash memory)(electronic), or an optical fiber (optical).

While various embodiments of the invention have been described, it willbe apparent to those of ordinary skill in the art that many moreembodiments and implementations are possible within the scope of theinvention. Accordingly, the invention is not to be restricted except inlight of the attached claims and their equivalents.

1-30. (canceled)
 31. A system comprising: a distributed computerarchitecture configured to service publish-subscribe events through filesystem commands including: a processor configured to invoke a first fileopen function in a file system application programming interface inresponse to a publisher application that causes the processor to prepareto publish one or more attributes of an object associated with apublish-subscribe file; the processor configured to invoke a file writefunction in the file system application programming interface thatcauses the processor to write or delete the one or more attributes ofthe object associated with the publish-subscribe file in response todata elements that accompany the file write function; the processorconfigured to invoke a second file open function in the file systemapplication program interface in response to a subscriber applicationthat the causes the processor to establish a subscription to thepublish-subscribe file identified by the subscriber application; theprocessor configured to invoke a notification to the subscriberapplication in response to the invocation of the file write functionexecuted by the file system; and the processor configured to invoke afile read function in the file system application programming interfacein response to the notification to the subscriber application thatincludes an identifier of the publish-subscribe file that causes theprocessor to publish the one or more attributes of the object associatedwith the publish-subscribe file that changed since a prior invocation ofthe file read function.
 32. The system of claim 31, where the processoris configured to create a publish-subscribe file associated with theobject when the first file open operation is invoked and thepublish-subscribe file does not exist.
 33. The system of claim 31, wherethe processor is configured to open, in a write-mode, thepublish-subscribe file associated with the object when the first fileopen operation is invoked.
 34. The system of claim 31, where theprocessor is configured to open, in a read-mode, the publish-subscribefile associated with the object when the second file open operation isinvoked.
 35. The system of claim 31, where the processor is programmedto execute the file read operation as a non-blocking event and returnsfrom the file read operation when no events associated with the objecthave been published since the prior invocation of the file readfunction.
 36. The system of claim 31, where the processor is programmedto execute the read operation as a blocking event and defers returningfrom the file read operation when no events associated with the objecthave been published since a prior invocation of the file read operation,until at least one event associated with the object is published. 37.The system of claim 31, where the file system application programminginterface comprises a POSIX compliant interface.
 38. The system of claim31 where: the processor is configured to invoke a third file openfunction in a file system application programming interface in responseto a second publisher application that causes the processor to prepareto publish a second object associated with a second publish-subscribefile named by the second publisher application; and the processorconfigured to invoke a further file write function in the file systemapplication programming interface that causes the processor to write ordelete one or more attributes of the second object associated with thesecond publish-subscribe file in response to data elements thataccompany the further file write invocation.
 39. The system of claim 38,further comprising: the processor configured to invoke a fourth fileopen function in the file system application program interface inresponse to a second subscriber application that the causes theprocessor to establish a second subscription to the secondpublish-subscribe file identified by the subscriber application; theprocessor configured to invoke a second notification to the secondsubscriber application in response to the invocation of the fourth filewrite function executed by the file system; and the processor configuredto invoke a second file read function in the file system applicationprogramming interface in response to the second notification to thesecond subscriber application that includes an identifier of the secondpublish-subscribe file that causes the processor to publish the one ormore attributes of the second object associated with the secondpublish-subscribe file that changed since a prior invocation of the fileread function.
 40. The system of claim 31, where the one or moreattributes of the object associated with the publish-subscribe filecomprises a quality parameter.
 41. The system of claim 40 where the oneor more attributes is written or deleted only when the quality parameteris equal to or greater than a prior quality parameter.
 42. A systemcomprising: a computer architecture configured to providepublish-subscribe functionality through file system commands: aprocessor configured to invoke a first file open function in a filesystem in response to a publisher application that causes the processorto prepare to publish one or more attributes of an object associatedwith a publish-subscribe file; the processor configured to invoke a filewrite function in the file system that causes the processor to write ordelete the one or more attributes of the object associated with thepublish-subscribe file in response to data elements that accompany thefile write invocation; the processor configured to invoke a second fileopen function in the file system in response to a subscriber applicationthat the causes the processor to establish a subscription to thepublish-subscribe file identified by the subscriber application; theprocessor configured to invoke a notification to the subscriberapplication in response to the invocation of the file write functionexecuted by the file system; the processor configured to invoke a fileread function in the file system in response to the notification to thesubscriber application that includes an identifier of thepublish-subscribe file that causes the processor to publish the one ormore attributes of the object associated with the publish-subscribe filethat changed since a prior invocation of the file read function.
 43. Thesystem of claim 42, where the processor is configured to create apublish-subscribe file associated with the object when the first fileopen operation is invoked and the publish-subscribe file does not exist.44. The system of claim 42, where the processor is configured to open,in a write-mode, a publish-subscribe file associated with the objectwhen the first file open operation is invoked.
 45. The system of claim42, where the processor is configured to open, in a read-mode, apublish-subscribe file associated with the object when the second fileopen operation is invoked.
 46. The system of claim 42, where theprocessor is programmed to execute the file read operations as anon-blocking event and returns from the file read operation when noevents associated with the object have been published since the priorinvocation of the file read function.
 47. The system of claim 42, wherethe processor is programmed to execute the read operation as a blockingevent and defers returning from the file read operation, when no eventsassociated with the object have been published since a prior invocationof the file read operation, until at least one event associated with theobject is published.
 48. The system of claim 42, where the file systemapplication programming interface comprises a POSIX compliant interface.49. The system of claim 42 where: the processor is configured to invokea third file open function in a file system in response to a secondpublisher application that causes the processor to prepare to publish anobject associated with a second publish-subscribe file identified by thesecond publisher application; and the processor configured to invoke afurther file write function in the file system that causes the processorto write or delete one or more attributes of a second object associatedwith the second publish-subscribe file in response to data elements thataccompany the further file write invocation.
 50. The system of claim 49,further comprising: the processor configured to invoke a fourth fileopen function in the file system in response to a second subscriberapplication that the causes the processor to establish a secondsubscription to the second publish-subscribe file identified by thesubscriber application; the processor configured to invoke a secondnotification to the second subscriber application in response to theinvocation of the fourth file write function executed by the filesystem; and the processor configured to invoke a second file readfunction in the file system in response to the second notification tothe second subscriber application that includes an identifier of thesecond publish-subscribe file that causes the processor to publish theone or more attributes of the second object associated with the secondpublish-subscribe file that changed since a prior invocation of the fileread function.